Network switches typically include ingress ports to receive data from one side, egress ports to send out data to the other side, and a switching fabric to cross-connect between ingress ports and egress ports. In packet communication networks, data is formed in a packet format which includes a packet header and a packet payload: the packet header specifies specific protocol information, and the packet payload carries customer information. A packet received from an ingress port is classified and processed based on a service provisioning/management policy before being sent out an egress port. A typical network switch may exchange data packets between multiple transport mediums according to multiple transport protocols when an ingress port and an egress port run different protocols over different transport mediums. Protocol translation between ingress and egress ports is required when a network switch is connected with multiple transport mediums to support multiple services/protocols.
More specifically, protocol translation is required to support the following two application scenarios: (1) to perform service interworking at a network edge to translate one type service/protocol to another type service/protocol, and (2) to provide gateway function to inter-connect two networks running different network protocols to translate from one type of protocol in one network to another type of protocol in another network. Although the applications appear differently, protocol translation, or more specifically protocol-specific packet format translation, is always required. FIG. 1A is a block diagram of a typical network switch 100. Ports 110-120 exchange data via switch 100 according to multiple transport protocols. If the switch supports N protocols, the switch can translate to and from anyone of N protocols. A typical method for performing protocol translation is using N-to-N protocol mapping and implementing all N2 possible protocol translations on the switch, and the protocol translation is typically performed during data ingress. For example, if the switch supports N=3 protocols where the protocols are ATM, Frame Relay, and MPLS, in principle, N2=9 protocol (“uni-directional”) translations are implemented as follows:                (ATM to ATM), (ATM to Frame Relay), (ATM to MPLS),        (Frame Relay to ATM), (Frame Relay to Frame Relay), (Frame Relay to MPLS),        (MPLS to ATM), (MPLS to Frame Relay), and (MPLS to MPLS).        
N-to-N protocol mapping with N2 protocol translations may not be desirable for several reasons. First, the development complexity for protocol translations is N2, not linear in N, which may be undesirable as N increases when new services are added to the switch. Secondly, processing tasks may be imbalanced between ingress and egress—for example, if protocol translations are mainly performed during data ingress, more processing tasks are performed during data ingress than during data egress. This may cause resource (processing power, memory, etc.) stress in data ingress and resource waste in data egress. Furthermore, adding a new service (or protocol type) to the switch requires implementing an additional 2N (“uni-directional”) protocol translations.
There is a need to improve the typical protocol translation architecture in a network switch to more efficiently handle multiple protocol translations, to provide more efficient processing for better resource utilization, and to simplify the addition of new services or protocols introduced to the switch incrementally.